The explosion of interest and reliance on the Internet has led to an increasing demand for increased data carrying capacity in networks. The nigh ubiquitous T1 standard is beginning to show its inadequacies for some applications. Unfortunately, users who need more than the T1's 1.544 mbps capacity used to have no recourse but to upgrade to the T3 standard operating at 44.736 mbps. This jump can be inconvenient for users who are only willing to pay for, at most, 20–30 mbps. One solution to the problem was the concept of “bundling” multiple T1 lines to arrive at higher speeds and capacities. This solution essentially involves aggregating multiple T1 lines or links and using them as a single link from the perspective of providing bandwidth.
While the “bundling” solution seemed to solve the problem theoretically, technical issues arose when implementing the solution. To optimize the bandwidth in the multiple link bundle, multiple link protocols (such as FRF.12/16 and RFC 1990/2686) were developed. These protocols called for dividing or fragmenting packets (units of data sent from one network node to another) into smaller elements. These fragments are then transferred across the multiple links simultaneously. This maximizes the link bandwidth available.
As an example, if a single packet takes x units of time to transfer over a single link, it should theoretically be possible to divide the packet into 5 smaller elements and transmit these five elements over 5 identical links. Such a transmissions should only take x/5 units of time. Of course, the above example ignores the overhead cost of fragmenting and, later on, reassembling the packet. It is this reassembly problem that can provide the most issues in implementing the “bundling” solution. Essentially, the system which implements the link bundling solution must:    1) transmit packets across the member links in the multiple link bundle;    2) fragment the packets while transmitting across the bundle to reduce skew and delay for packet transfers;    3) support multiple simultaneous fragmentation sessions; (this is needed to support multiple independent multiple link bundles and also multiple independent multiple link sessions within a single bundle); and    4) receive data from all the links, reassemble the data into fragments, and then into packets.
Current solutions for the reassembly problem have their own drawbacks. U.S. Pat. No. 5,590,122 issued to Sandorfi et al and U.S. Pat. No. 5,396,490 issued to White et al have proposed solutions directed at packet reassembly but they do not specifically address multiple link applications. Other solutions suffer from the following drawbacks:    a) a low number of bundles supported due to the processing requirements of the bundle reassembly;    b) supporting only a single reassembly session per bundle;    c) supporting a small number of aggregate bundles due to processing and memory limitations;    d) an assumption that all links operate at the same speed to simplify the processing; and    e) line rate processing of all small packets is often limited to the overhead associated with processing each packet.
From the above, there is therefore a need for a solution that can, among other things, support multiple reassembly sessions, support large numbers of bundles and a large number of channels within those bundles, and also be transparent to differing link speeds.